Method and apparatus for creating and deploying applications from a server application

ABSTRACT

In a system where client and server components (or actors) of an application are organized as complementary hierarchical graphs, a method and apparatus for creating server applications and dynamically deploying server applications on a client system are described. The server graph comprises, as a minimum, server nodes corresponding to the union of all possible client nodes, whereas each client graph corresponds to a subset of the related server nodes. The server graph is a compound tree from which all possible combinations of client trees can be dynamically created. At a desired time, for example, when the client requests for a client tree representation, the server creates the client tree representation using a peeling process to determine which nodes in the server actor tree should be included in the client tree representation. The peeling process involves determining the server actor nodes that meet a set of criteria for the particular client. The generated client tree structure contains objects that are shipped via a secured communication interface to the client in a tree structure.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to the field of computer applications, and, morespecifically, to object-oriented client-server applications.

Sun, Sun Microsystems, the Sun logo, Java, Java 3D and all Java-basedtrademarks and logos are trademarks or registered trademarks of SunMicrosystems, Inc. in the United States and other countries. All SPARCtrademarks are used under license and are trademarks of SPARCInternational, Inc. in the United States and other countries. Productsbearing SPARC trademarks are based upon an architecture developed by SunMicrosystems, Inc.

2. Background Art

In monolithically designed object-oriented computer applications,program code is developed as a collection of objects linked as an“object web.” Each object encapsulates its own data, as well as methodsfor operating on that data. In the execution of the application,messages are sent between objects, calling the various methods toimplement the application. However, more and more frequently,applications are being designed as distributed in nature. That is,elements of the application may exist in separate executionenvironments, sometimes resident within the same computer system, butmore often executed in multiple computer systems coupled via a network.An example of such a distributed scheme is the client-server paradigm.Unfortunately, as described below, it is difficult for monolithicdistributed applications to provide efficient communication between thedistributed elements of the application.

In a client-server application, the functionality of the application issplit between two primary locations, i.e., the “client” and the“server.” In many cases, the same server will interface with multipleclients, e.g., for common access to a database or shared services. Inthis type of environment, for a monolithically designed application,communication is generalized into simple client-server messagestransmitted over a common communication channel.

Typically, one communication object or component of the client receivesall outgoing message requests from the application objects local to theclient. Those outgoing message requests are packaged (e.g., as a networkpacket) and sent via the common channel to the server. At the server,another communication object receives the packaged message. Thecommunication object, or other server resident object, must thendetermine what the message is regarding (i.e., what is the messagecontext) and which object on the server should handle the message. It ispossible that the message will be processed in this manner by multipleobjects before being forwarded to the desired target object on theserver. The same communication procedure is repeated over the commoncommunication channel for communications originating from the server forprocessing by the client.

The process of determining the message context and identifying theappropriate target object can be non-trivial, particularly for largeapplications. Because the application is monolithic in nature, it maynot be obvious which object should handle a message having a particularcontext. Extra effort may be needed to predetermine what sort of messagecontexts each object can handle, and organize this predeterminedinformation into a useful format. The application structure must thenremain fixed in order for this predetermined information to remainvalid. Constraining the application to a static configuration in thisway undesirably eliminates any dynamic flexibility in the application,making improvements and alterations to the application more complicated.Efforts are thus needed to improve the efficiency of communication indistributed applications without constraining the flexibility of thoseapplications.

Improving communication in distributed applications require a complexoperating architecture and creates a challenge for the designer byrequiring development of server side objects and, possibly, multipleclient side objects for different clients communicating with the sameserver side object. Thus, a method is needed to improve design ofarchitectures for distributed applications.

Efforts in the organization of applications include the development ofhierarchical tools referred to as “scenegraphs,” which are used toorganize rendering applications as directed acyclic graphs. Adescription of scenegraph techniques is provided below.

Scenegraph Techniques

A scenegraph is a tree structure comprising a multiplicity of nodesinterconnected in a hierarchical manner. This hierarchical structureprovides a well-organized framework for software applications, and onein which functionality may be easily augmented through the addition ofone or more nodes to an existing scenegraph. Individual functionalapplication elements are constructed as separate node objects andconnected together in a treelike structure. Those node objects are thenmanipulated using their predefined accessor, mutator and node-linkingmethods.

For reference, an object is a programming unit that groups together adata structure (one or more instance variables) and the operations(methods) that can use or affect that data. Thus, an object consists ofdata and one or more operations or procedures that can be performed onthat data. An object can be instructed to perform one of its methodswhen it receives a “message.” A message is a command or instruction sentto the object to execute a certain method. A message consists of amethod selection (e.g., method name) and zero or more arguments. Amessage tells the receiving object what operations to perform.

Any given object is an “instance” of a particular class. A classprovides a definition for an object which typically includes both fields(e.g., variables) and methods. (The term “object” by itself is oftenused interchangeably to refer to a particular class or a particularinstance.) An instance of a class includes the variables and methodsdefined for that class. Multiple instances can be created from the sameclass.

In the construction of a scenegraph, a child node object is attached toa parent group node object by calling the “addChild” method of theparent node object and specifying the child node object in the inputfield. A reference to the child node object is then stored in the parentnode object, enabling general scenegraph mechanisms, such as traversalmethods, to be implemented between the parent and child node objects.Other specific mechanisms for linking child nodes may be implemented forspecific node object types. Also, constraints may be placed on whattypes of node objects may be linked as children to other specific nodetypes to enforce particular nodal relationships of scenegraphimplementations.

Scenegraphs are currently used in graphics rendering applications. Thescenegraph contains a complete description of the entire scene, orvirtual universe. This includes the geometric data, the attributeinformation, and the viewing information needed to render the scene froma particular point of view. In the case of a 3D scene, the scenegraphhierarchy promotes a spatial grouping of geometric objects found at theleaves (i.e., end nodes) of the scenegraph. Internal nodes act to grouptheir children together. A group node may also define a spatial boundthat contains all the geometry defined by its descendants. Spatialgrouping allows for efficient implementation of operations such asproximity detection, collision detection, view frustrum culling andocclusion culling.

Node objects of a scenegraph may be separated into “group node” objectsand “leaf node” objects. Group node objects group together one or morechild nodes, and can be used to define behavior or relationships commonto those child nodes. A leaf node has no children and only one parent.The state of a leaf node includes any state in a direct path between theleaf node and the source or “root” node of the scenegraph. In thecontext of a graphics scene, leaf node objects contain the actualdefinitions of shapes (geometry), lights, fog, sound, etc. When a sceneis rendered, the renderer incorporates all state changes made in adirect path from the root node of the scenegraph to a leaf node objectin the drawing of that leaf node object.

FIG. 1 illustrates a general scenegraph structure used to represent a 3Dscene in accordance, for example, with scenegraph policies as describedin the Java 3D™ API Specification available from Sun Microsystems, Inc.The scenegraph of FIG. 1 comprises a single root node, referred to asvirtual universe (VU) 100, one or more locale nodes (LO) 101, one ormore branch group nodes (BG) 102, one or more group nodes (GN) 103, andone or more leaf nodes (LN) 104.

Virtual universe 100 represents the center of the scene, with all childnodes being positioned relative to it. One or more high-resolutionlocale nodes 101 are coupled to virtual universe 100. Each such localenode 101 specifies a relative offset position with respect to virtualuniverse 100. This relative offset is represented in a high-resolutionformat to accommodate distance relationships comparable to the smallestand largest conceived distances in the real world. Each locale node 101may be used to attach one or more branch group nodes 102, whoserendering positions are interpreted relative to the given locale node101.

Branch group nodes 102 generally act as a root node of a subgraphassociated with the given parent locale node 101. When a branch groupnode 102 is attached to a locale node 101, and hence to a virtualuniverse 100, the branch group node and its descendants are considered“live” (i.e., ready to render) with respect to the scene. One or moregeneral group nodes 103 may be attached as child nodes to each branchgroup node 102. Each group node 103 may support zero or more child nodesin the form of further group nodes 103 or leaf nodes 104.

An example of an implementation of a group node 103 is as a transformnode that contains a transform matrix used to scale, rotate, andposition its descendants. Other group nodes implemented as “behavior”nodes may be used to embody algorithms for modifying the transformmatrices of specified transform objects. Certain leaf node objects mayalso have references to component objects (not shown) which specifyspecific attributes of the given leaf node object (e.g., a shape leafnode may have as associated component objects a geometry componentobject, specifying a geometric shape of the shape leaf node, and anappearance component object, specifying the appearance of the shape interms of color, texture, etc.). One leaf node is typically used torepresent the viewing platform for rendering purposes, with associatedcomponent objects for specifying attributes of the rendering viewpoint,as well as the canvas or screen on which the rendered output is to bedisplayed.

SUMMARY OF THE INVENTION

A method and apparatus for creating server applications and dynamicallydeploying server applications on a client system are described. In oneor more embodiments, client and server components (or actors) of anapplication are organized as complementary hierarchical graphs, such astrees or directed acyclic graphs. One or more nodes in the server graphare linked via a distributed communication interface to the respectivepeer nodes in each of the client graphs.

In one or more embodiments, the server graph comprises, as a minimum,server nodes corresponding to the union of all possible client nodes,whereas each client graph corresponds to a subset of the related servernodes. The server graph is a compound tree from which all possiblecombinations of client trees can be dynamically created. The sourcecreator or designer only needs to create the source actors, unlike inthe prior art where the creator must also create the client actors.

In one or more embodiments of the present invention, the client treerepresentation is created at a desired time. For example, when theclient requests for a client tree representation, the server creates theclient tree representation using a peeling process to determine whichnodes in the server actor tree should be included in the client treerepresentation. In one or more embodiments, the peeling process involvesdetermining the server actor nodes that meet a set of criteria for theparticular client. The generated client tree structure contains objectsthat are shipped, via secure communication, to the client in a treestructure. The client uses this tree representation to generate theclient actor graph, thus, dynamic creation of unique client actor graphsfrom the compound server actor graph.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a general embodiment of a scenegraph forrepresenting 3D scenes.

FIG. 2 is a process flow illustrating generation of the client tree fromthe server tree in accordance with an embodiment of the invention.

FIG. 3 is a block diagram of an example client-server applicationcomprising complementary graphs of actors, in accordance with anembodiment of the invention.

FIG. 4 is a block diagram of a client-server system with externalsources in accordance with an embodiment of the invention.

FIG. 5 is a flow diagram illustrating the peeling process in accordancewith an embodiment of the invention.

FIG. 6 is a block diagram of a processing environment comprising anobject-oriented runtime environment capable of providing a suitablesoftware execution environment for an embodiment of the invention.

FIG. 7 is a block diagram of one embodiment of a computer system capableof providing a suitable hardware execution environment for an embodimentof the invention.

DETAILED DESCRIPTION OF THE INVENTION

The invention is a method and apparatus for creating server applicationsand for dynamically deploying server applications on a client system. Inthe following description, numerous specific details are set forth toprovide a more thorough description of embodiments of the invention. Itwill be apparent, however, to one skilled in the art, that the inventionmay be practiced without these specific details. In other instances,well known features have not been described in detail so as not toobscure the invention.

Embodiments of the invention are directed at creating and deployingclient components for applications having complementary client andserver components that are organized as hierarchical graphs or trees.Example peer node architecture wherein showing applications withcomplementary client and server components is described in copendingU.S. patent application Ser. No. 09/691,407, entitled “Method andApparatus for Organizing Elements of a Server Application in aClient-Server System,” filed on Oct. 17, 2000, and assigned to thepresent assignee, the specification and figures of which are hereinincorporated by reference.

In the peer node structure, server application architecture utilizesobject graph organization to reflect the structure of the client and toconnect more intimately with the internal nodes of the client. Actorsare used as building blocks for applications, where each actor is aself-contained hierarchical graph of objects. More specifically, aserver application and one or more associated client applications areorganized as complementary hierarchical graphs of actors, where eachactor node on the client has a corresponding peer actor node on theserver. Those aspects of the application that are server specific areimplemented in the server actor node and are referred to as the sourceactor. The client specific aspects of the application are implemented inthe peer actor node of the client and are referred to as the memberactor. Communication between the clients and the server is performedbetween peer nodes so that communication protocol and context are welldefined.

Where a hierarchical graph is implemented with actors, the subtrees ofnodes within each actor are private with respect to one another.Separate secured runtime environments (sometimes referred to as security“sandboxes”) may be used to support the execution of object codeassociated with actor subtrees, thus preventing, for example, onesubtree from violating the memory space of another. Object code and dataare therefore kept private, except where authorized access is providedby an appropriate interface.

External and often remote applications may be associated with one ormore source actors in the client-server system. A distribution manageractor provides a secure interface between an external application andthe corresponding source actor(s) in the server. The secure interfacecomprises mechanisms for attaching the external application to, anddetaching from, the source actor(s) in the server, as well as forupdating and retrieving data from the source actor(s).

The hierarchical graph is a directed acyclic graph such as a scenegraph.Nodes of the client and server graphs may include active nodes thatfunction like scenegraph elements (e.g., branch group nodes), but withfurther control functions. Each active node in the server graph isconnected with its peer in the client graph, and may also be connectedto other resources, such as an external media source. For example,access control nodes are branch group nodes that determine whether, andunder what terms, the subgraph below them in the hierarchy is visible orotherwise accessible to the user. In the course of making thisdetermination, an access control node may interact with databases orother server side resources through the server resident peer node. Ingeneral, active nodes concern themselves with the portion of the actorgraph at or below their point of attachment. Whereas active nodes on theclient typically contain information and functions dedicated solely tothat client and its user, active nodes on the server contain informationand functions directed at all clients for which a corresponding peernode is implemented.

Complementary Server and Client Graphs

FIG. 3 is a block diagram of an example client-server applicationcomprising complementary graphs of actors, in accordance with one ormore embodiments of the invention. The application comprises servercomponent 300 and one or more client components (e.g., 301A and 301B).The server and client components each comprise a hierarchical graph ofactors, with each client component being complementary to a subtree ofthe server component.

In FIG. 3, server component 300 comprises server root node 302S linkedto group actor 303S. Group actor 303S acts as the group resource nodefrom which the primary media sources of this example (i.e., source Aactor 304S, source C actor 305S and source B actor 306S) are linked.Source A actor 304S and source B actor 306S are linked to subsource Aactor 307S and subsource B actor 308S, respectively.

In this example, client 301A is concerned only with the media providedby source A, subsource A and source C. Actors associated with source Band subsource B are therefore not necessary to the function of client301A and may be omitted. Otherwise, client 301A mirrors the tree ofactors presented by server 300. Client component 301A comprises clientroot node 302A linked to group actor 303A. Group actor 303A is linked tomember A actor 304A and member C actor 305A. Member A actor 304A isfurther linked to submember A actor 307A. As previously noted, a memberactor is the version of the actor component that resides on the clientand the source actor is the version of the actor component residing onthe server therefore, the tree actors on the client mirror the treeactors on the server.

Unlike client 301A, client 301B is concerned with source B, subsource Band source C, but not with source A or subsource A. Therefore, the actortree of client component 301B comprises client root node 302B linked togroup actor 303B. Group actor 303B is linked to member B actor 306B andmember C actor 305B. Member B actor 306B is further linked to submemberB actor 308B.

Each actor within a client component is linked with its respectivecomplementary actor in the server component. By distributing theclient-server communication interface at the actor level, more directedcommunication is achieved. There is no need to determine the targetobject or context for messages transmitted between the client andserver. All messages are provided directly to that portion of the objectcode that is configured to handle the communication. For example, in thedescribed media application, a source actor at the server may beconfigured to obtain media content, and forward the media contentdirectly to the corresponding actor at the client which is then able toefficiently render the media content. More efficient client-serverinteraction is thus achieved.

As shown in FIG. 3, examples of possible actors may include source andsubsource actors. These may include content or media input and/or outputelements that obtain content from or submit content to other remoteapplication entities, referred to as “distribution sources” and“distribution subsources,” that are linked to the server applicationcomponent. An example of a distribution source may be a network entitythat provides media content such as video or audio data to the servercomponent of a cable programming or pay-per-view application. Adistribution subsource may be, for example, a sponsor advertisementsource that is associated with the primary source to which it is linked.

For these systems, in which client graphs contain varying subsets of thepeer nodes contained in the server graph, the design, deployment, anddynamic modification of the system may be problematic. To resolve theseproblems, the server application is designed to contain a full supersetof peer nodes for all possible client configurations such that therepresentation of a specific client configuration may be dynamicallygenerated or updated from the full superset of peer nodes based on a setof access control parameters. The parameter set may be different fordifferent clients thereby providing a peer node architecture that isflexible. For example, the parameter set may contain information aboutthe capabilities of the client, tasks to be performed by the client, oroptions subscribed by the client, etc. The flexibility provided by thepresent invention makes it possible to dynamically determine individualclient tree configurations based on user activities and external events.

One or more embodiments of the present invention teaches a serverapplication graph with a full superset of peer nodes. The server sideapplication design uses any set of API's (Application Program Interface)that have built-in ability to be actively accessed by a peelingmechanism. The complementary client graph is generated, one node at atime, by this peeling method. Peeling is a process whereby the servergraph (actor tree) is traversed, selectively ignoring or includingindividual branches in the graph based on evaluation of a multiplicityof parameters. The client graph representation is subsequentlytransferred by a known means to one or more clients. Example mechanismsfor transporting client graph information over a network are describedin copending U.S. patent application Ser. No. 09/551,522, entitled“Method and Apparatus for Transport of Scenegraph Information Across aNetwork,” filed on Apr. 18, 2000, and assigned to the present assignee,the specification and figures of which are herein incorporated byreference.

Upon receiving the client graph representation, each client uses theinformation to build an instance of the desired Client Object graph.Thus creating a complementary application on the client that mirrors asubset of the application on the server.

FIG. 2 shows a process for generating and installing a client actor treefrom a server actor tree. A request is received from the client for aclient-tree representation of the desired application from the client instep 200. In one or more embodiments, the request may be in the form ofan object that is obtained from the server. For example, it could bethat a dynamic change occurred in the server actor tree and the serverneeds to update an existing client actor tree. It could also be anobject provided by a client in a federated environment. Thus, at step200, all that is required is a need for either a new client tree or anupdate to an existing tree.

At step 210, a parameter set for the specific client and environment isobtained. For example, the parameter set may be an object providedduring application initialization in the server. In one or moreembodiments, the parameter set is obtained from the client. Theparameter set may also be resident in the source actor. For example, thesource actor may have built-in definitions of the applicable clienttypes. At step 220, a determination is made whether a client treerepresentation has previously been created for this client. If so, theserver creates the client graph representation at step 230 using thepeeling process described below, otherwise, it creates a subgraph withwhich to dynamically modify the existing client actor tree at step 240.After the client graph representation is generated at step 230 or theclient subgraph is generated at step 240, the client graph or subgraphrepresentation is shipped to the client in the form of pre-initializedobjects in a secure manner for construction or modification of theclient side actor tree.

Peeling Process

A compound ad hoc server application is required to dynamically create aclient graph object for an application that works regardless of themethod of constructing the client application actors. The server actortree can be traversed in a parametric manner to create a desired clientactor tree. Since client actor trees may differ, i.e. depending on theneeds of the client, parametric determination of the server actorsrepresented in each client tree is performed.

The peeling process provides a unique way of developing the client fromthe server side. Defining the client from the server side allows thedesigner to design only the server side (i.e. source) actors. The serverside actors plug into the tree in some arbitrary place to create acompound tree of actors. At different places and instances, and atclient desired times, a set of API's are available that allow traversalof the entire compound tree of server actors to produce the functionalclient tree.

FIG. 4 is a block diagram of a client-server environment withdistribution sources and subsources in accordance with one or moreembodiments of the invention. As shown, a server component 400 is linkedto one or more (1-N) client components 401 and one or more (1-M)distribution sources 402. Each distribution source may also be servicedby one or more (1-K) distribution subsources 403 (shown here linked todistribution source 1).

The content provided by each distribution subsource is composited withthe content of its respective parent distribution source, so that nestedcontent sourcing may be implemented transparently to the servercomponent 400, as well as any further distribution sources higher in thedistribution hierarchy. That is, a parent distribution source is awareof its child distribution subsource, however, for some embodiments, theparent will be unaware of the existence of any “grandchildren”distribution subsources beneath the level of its child subsource.

In one or more embodiments, application security rules and operatingboundaries, sometimes referred to as security “sandboxes,” are definedat each layer in the distribution source hierarchy such that each parentdistribution source/subsource (as well as the server component 400) isprevented from intentionally or unintentionally disturbing the specificcontent provided from distribution subsources lower in the distributionhierarchy, or from interfering with the operation of the lowerdistribution sources/subsources. Distribution sources and subsources cantherefore be ensured of the quality and accuracy of their respectivecontent when that content is ultimately provided via server component400 to one or more clients 401.

A complementary mechanism is provided by which the top-leveldistribution source 402 may interact with the corresponding distributionsource actor in the server component 400. The same or similar mechanismmay be used by distribution subsources to interact with a correspondingactor in a respective parent distribution source. The server actor treethus formed, the peeling process generates the respective client treerepresentation based on predetermined set of parameters.

FIG. 5 is a flow diagram of the peeling process. At step 500, a clienton the network requests a tree representation from the server (i.e.source provider). At step 505, the server obtains the parameter set forthe requesting client. The parameter set contains data and/or criteriafor generating the client tree representation. The parameter set may beobtained from the client, the server, or from the source actor itself.For example, the parameter set may be obtained from an object providedby the client or from data stored on the network for such clientconfiguration. After obtaining the parameter set, the server starts thepeeling process to generate the client tree representation.

At step 510, the server selects a first node from its source actor tree.In one or more embodiments, the starting (i.e. first) node is the rootnode and proceeds branch by branch. At step 520, a determination is madewhether based on the information in the parameter set, the selectedserver node is a desired node in the client actor tree. A server nodemay be a desired node if the client ordered that particular node, or ifthe node itself satisfies other criteria for inclusion. For example, thepeeling process may query the selected node to determine, at step 520,if it is the node ordered by the client.

In one or more embodiments, the selected server actor node wouldmaintain the criteria for inclusion in the form of data, for example.The peeling process would have access to the data in the node and usesit for determination whether the current criteria are met. For example,the peeling process may compare the data in the node with data in aparameter obtained for the client to make the determination.

If a determination is made at step 520 that the selected node is adesired node, then at step 525 a pre-initialized object containingmethods and attributes for the construction and initialization of theclient graph (i.e. a fully initialized description of the client node)is obtained from the selected server actor node. At step 530 thepre-initialized object of the selected node is added to the client-treerepresentation, otherwise, it is ignored. In either case, processingproceeds to step 540. At step 540, the peeling process determines ifthere are any remaining server-actor nodes for processing. If there areany remaining nodes, processing continues at step 550 to select the nextnode and then the cycle continues to step 520 until all the nodes andbranches in the server actor tree have been traversed.

During traversal of the server actor tree on a node-by-node basis, whena desired node is encountered, at step 530, the server requests for thefully initialized description of the client node from the node's API.The node's API provides the information in the form of an object thatcan be sent to the client in a tree structure. A client actor treerepresentation is generated at completion of processing of all the nodesin the server actor tree. At step 560 the client actor treerepresentation is shipped to the client via secure communication. At theclient side, the client uses this representation to create its uniquetree.

The peeling process allows the server graph to be traversed in aselective manner to produce a client graph from only a subset of theserver graph. It also provides the server the ability to produce amultiplicity of client graphs (e.g. for different clients) fromdifferent subsets of its server graph.

Embodiment of a Processing Environment

An embodiment of the invention is directed, though not limited, todistributed applications, such as those in which a server applicationserves one or more client applications. Such systems may be implementedusing object-oriented programming environments that produce executablesoftware objects. To facilitate object compatibility between the clientand server, the software objects may be implemented in a platformindependent manner, or the client and server systems may share common orcompatible operating platforms. The clients and server may executewithin separate machine or virtual machine runtime environments, withina single runtime environment, or a combination of the foregoingarrangements. The following description refers to an embodiment of avirtual machine-based runtime environment, though it will be obviousthat the invention is not limited to such.

Applications typically comprise one or more object classes. Classeswritten in high-level programming languages, such as the Java™programming language, may be compiled into machine independent bytecodeclass files. Alternatively, classes may be compiled into machinedependent, executable program code for direct execution by a givenhardware platform. In the machine independent case, each class filecontains code and data in a platform-independent format called the classfile format. The computer system acting as the execution vehiclecontains a program called a virtual machine, which is responsible forexecuting the code in each class file. (A hardware system may also beused that directly executes bytecode of class files.)

In a virtual machine environment, the classes of an application areloaded on demand from the network (stored on a server), or from a localfile system, when first referenced during the application's execution.The virtual machine locates and loads each class file, parses the classfile format, allocates memory for the class's various components, andlinks the class with other already loaded classes. This process makesthe code in the class readily executable by the virtual machine.

FIG. 6 illustrates the compile and runtime environments for an exampleprocessing system. In the compile environment, a software developercreates source files 600, which contain the programmer readable classdefinitions written in the source programming language, including datastructures, method implementations and references to other classes.Source files 600 are provided to pre-compiler 601, which compiles sourcefiles 600 into “.class” files 602 that contain bytecodes executable by avirtual machine. Bytecode class files 602 are stored (e.g., in temporaryor permanent storage) on a server, and are available for download over anetwork. Alternatively, bytecode class files 602 may be stored locallyin a directory on the client platform.

The runtime environment contains a virtual machine (VM) 605 which isable to execute bytecode class files and execute native operating system(“O/S”) calls to operating system 609 when necessary during execution.Virtual machine 605 provides a level of abstraction between the machineindependence of the bytecode classes and the machine-dependentinstruction set of the underlying computer hardware 610, as well as theplatform-dependent calls of operating system 609.

Class loader and bytecode verifier (“class loader”) 603 is responsiblefor loading bytecode class files 602 and supporting class libraries 604into virtual machine 605 as needed. Class loader 603 also verifies thebytecodes of each class file to maintain proper execution andenforcement of security rules. Within the context of runtime system 608,either an interpreter 606 executes the bytecodes directly, or a“just-in-time” (JIT) compiler 607 transforms the bytecodes into machinecode, so that they can be executed by the processor (or processors) inhardware 610.

The runtime system 608 of virtual machine 605 supports a general stackarchitecture. The manner in which this general stack architecture issupported by the underlying hardware 610 is determined by the particularvirtual machine implementation, and reflected in the way the bytecodesare interpreted or JIT-compiled. Other elements of the runtime systeminclude thread management (e.g., scheduling) and garbage collectionmechanisms.

Embodiment of Computer Execution Environment (Hardware)

An embodiment of the invention can be implemented as computer softwarein the form of computer readable code executed on any computerprocessing platform, or in the form of software (e.g., bytecode classfiles) that is executable within a runtime environment running on such aprocessing platform. An embodiment of the invention may be implementedin any type of computer system or programming or processing environment,including embedded devices (e.g., web phones, set-top boxes, etc.) and“thin” client processing environments (e.g., network computers (NC's),etc.). An example of a general computer system is illustrated in FIG. 7.The computer system described below is for purposes of example only.

In FIG. 7, keyboard 710 and mouse 711 are coupled to a system bus 718.The keyboard and mouse are for introducing user input to the computersystem and communicating that user input to processor 713. Othersuitable input devices may be used in addition to, or in place of, themouse 711 and keyboard 710. I/O (input/output) unit 719 coupled tosystem bus 718 represents such I/O elements as a printer, A/V(audio/video) I/O, etc.

Computer 700 includes a video memory 714, main memory 715 and massstorage 712, all coupled to system bus 718 along with keyboard 710,mouse 711 and processor 713. The mass storage 712 may include both fixedand removable media, such as magnetic, optical or magnetic opticalstorage systems or any other available mass storage technology. Bus 718may contain, for example, address lines for addressing video memory 714or main memory 715. The system bus 718 also includes, for example, adata bus for transferring data between and among the components, such asprocessor 713, main memory 715, video memory 714 and mass storage 712.Alternatively, multiplexed data/address lines may be used instead ofseparate data and address lines.

In one embodiment of the invention, the processor 713 is a SPARC™microprocessor from Sun Microsystems, Inc. or a microprocessormanufactured by Intel, such as the 80×86, or Pentium processor, or amicroprocessor manufactured by Motorola, such as the 680×0 processor.However, any other suitable microprocessor or microcomputer may beutilized. Main memory 715 is comprised of dynamic random access memory(DRAM). Video memory 714 is a dual-ported video random access memory.One port of the video memory 714 is coupled to video amplifier 716. Thevideo amplifier 716 is used to drive the cathode ray tube (CRT) rastermonitor 717. Video amplifier 716 is well known in the art and may beimplemented by any suitable apparatus. This circuitry converts pixeldata stored in video memory 714 to a raster signal suitable for use bymonitor 717. Monitor 717 is a type of monitor suitable for displayinggraphic images. Alternatively, the video memory could be used to drive aflat panel or liquid crystal display (LCD), or any other suitable datapresentation device.

Computer 700 may also include a communication interface 720 coupled tobus 718. Communication interface 720 provides a two-way datacommunication coupling via a network link 721 to a local network 722.For example, if communication interface 720 is an integrated servicesdigital network (ISDN) card or a modem, communication interface 720provides a data communication connection to the corresponding type oftelephone line, which comprises part of network link 721. Ifcommunication interface 720 is a local area network (LAN) card,communication interface 720 provides a data communication connection vianetwork link 721 to a compatible LAN. Communication interface 720 couldalso be a cable modem or wireless interface. In any such implementation,communication interface 720 sends and receives electrical,electromagnetic or optical signals which carry digital data streamsrepresenting various types of information.

Network link 721 typically provides data communication through one ormore networks to other data devices. For example, network link 721 mayprovide a connection through local network 722 to local server computer723 or to data equipment operated by an Internet Service Provider (ISP)724. ISP 724 in turn provides data communication services through theworld wide packet data communication network now commonly referred to asthe “Internet” 725. Local network 722 and Internet 725 both useelectrical, electromagnetic or optical signals which carry digital datastreams. The signals through the various networks and the signals onnetwork link 721 and through communication interface 720, which carrythe digital data to and from computer 700, are exemplary forms ofcarrier waves transporting the information.

Computer 700 can send messages and receive data, including program code,through the network(s), network link 721, and communication interface720. In the Internet example, remote server computer 726 might transmita requested code for an application program through Internet 725, ISP724, local network 722 and communication interface 720.

The received code may be executed by processor 713 as it is received,and/or stored in mass storage 712, or other non-volatile storage forlater execution. In this manner, computer 700 may obtain applicationcode in the form of a carrier wave. Application code may be embodied inany form of computer program product. A computer program productcomprises a medium configured to store or transport computer readablecode or data, or in which computer readable code or data may beembedded. Some examples of computer program products are CD-ROM disks,ROM cards, floppy disks, magnetic tapes, computer hard drives, serverson a network, and carrier waves.

Thus, a method and apparatus for organizing elements of a serverapplication in a client-server system have been described in conjunctionwith one or more specific embodiments. The invention is defined by theclaims and their full scope of equivalents.

1. In a computer system, a method comprising: generating one or more actors on a server, wherein each of said one or more actors is a functional component of a distributed application; linking said one or more actors on the server in a first hierarchical tree; generating a dataset corresponding to a second hierarchical tree, wherein the second hierarchical tree is a subset of the first hierarchical tree; wherein each node in said first hierarchical tree comprises a source actor, each node in the replicated second hierarchical tree comprises a member actor, and each member actor corresponds to a respective source actor and wherein a first Portion of a function to be performed by the distributed application is executed by the member actor and a second portion of the function to be performed by the distributed application is executed by the source actor; sending said dataset to a client; replicating the second hierarchical tree in said client using said dataset, wherein said replicating comprises generating one or more peer actors on the client, and wherein said one or more peer actors on the client comprise executable code for performing tasks that are in addition to tasks performed by the one or more actors on the server; and providing a communication link between each of said one or more peer actors of the replicated second hierarchical tree on the client and a corresponding actor of the second hierarchical tree on the server.
 2. The method of claim 1, wherein each said actor comprises a tree of hierarchically linked nodes, said nodes comprising one or more objects.
 3. The method of claim 2, wherein said nodes further comprise one or more nested actors.
 4. The method of claim 1, wherein said sending said dataset comprises sending said dataset via a secure communication network.
 5. The method of claim 1, wherein said generating a dataset comprises: obtaining inclusion criteria from one or more parameter sets; traversing said first hierarchical tree to determine nodes of said first hierarchical tree that comply with said inclusion criteria; obtaining a pre-initialized object for each of said nodes that comply with said inclusion criteria; generating a client graph comprising said pre-initialized objects.
 6. The method of claim 5, wherein said traversing said first hierarchical tree is on a node-by-node basis starting from the root node and proceeding through all the leaf nodes.
 7. The method of claim 5, wherein said dataset is indicative of the full client graph.
 8. The method of claim 1, wherein said dataset comprises a subgraph for updating the replicated second hierarchical tree of said client.
 9. The method of claim 5, wherein said pre-initialized-object comprises methods and attributes for construction and initialization of said client graph.
 10. A computer program product comprising: a computer readable medium having computer program code embodied therein for creating and deploying client side actors for a server application, said computerreadable medium comprising computer program code configured to cause a computer to: generate one or more actors on a server, wherein each of said one or more actors is a functional component of a distributed application; link said one or more actors on the server in a first hierarchical tree; generate a dataset corresponding to a second hierarchical tree, wherein the second hierarchical tree is a subset of the first hierarchical tree; wherein each node in said first hierarchical tree comprises a source actor, each node in the replicated second hierarchical tree comprises a member actor, and each member actor corresponds to a respective source actor and wherein a first portion of a function to be performed by the distributed application is executed by the member actor and a second portion of the function to be performed by the distributed application is executed by the source actor; send said dataset to a client; replicate the second hierarchical tree in said client using said dataset, wherein to replicate the second hierarchical tree, the computer program code is further configured to cause a computer to generate one or more peer actors on the client, and wherein said one or more peer actors on the client comprise executable code for performing tasks that are in addition to tasks performed by the one or more actors on the server; and provide a communication link between each of said one or more peer actors of the replicated second hierarchical tree on the client and a corresponding actor of the second hierarchical tree on the server.
 11. The computer program product of claim 10, wherein each said actor comprises a tree of hierarchically linked nodes, said nodes comprising one or more objects.
 12. The computer program product of claim 11, wherein said nodes further comprise one or more nested actors.
 13. The computer program product of claim 10, wherein said send said dataset comprises sending said dataset using a secure communication network.
 14. The computer program product of claim 10, wherein said generate a dataset comprises: obtaining inclusion criteria from a parameter set; traversing said first hierarchical tree to determine nodes of said first hierarchical tree that comply with said inclusion criteria; obtaining a pre-initialized object for each of said nodes that comply with said inclusion criteria; generating a client graph comprising said pre-initialized objects.
 15. The computer program product of claim 14, wherein said traversing said first hierarchical tree is on a node-by-node basis starting from the root node and proceeding through all the leaf nodes.
 16. The computer program product of claim 14, wherein said dataset is indicative of the full client graph.
 17. The computer program product of claim 10, wherein said dataset comprises a subgraph for updating the replicated second hierarchical tree of said client.
 18. The computer program product of claim 13, wherein said pre-initialized object comprises methods and attributes for construction and initialization of said client graph.
 19. An apparatus comprising: a server comprising one or more server actors linked in a source hierarchical tree, wherein each of said one or more actors is a functional component of a distributed application; one or more clients, each of said clients coupled to the server via a respective communication interface; wherein said server is configured to: generate a dataset for each of said one or more clients, wherein each dataset corresponds to a respective subset of the source hierarchical tree; wherein each node in said first hierarchical tree comprises a source actor, each node in the replicated second hierarchical tree comprises a member actor, and each member actor corresponds to a respective source actor and wherein a first portion of a function to be performed by the distributed application is executed by the member actor and a second portion of the function to be performed by the distributed application is executed by the source actor; send each dataset to the respective client via the respective communication interface; wherein each of said one of more clients is configured to replicate a respective subset of the source hierarchical tree based on said dataset, wherein to replicate a respective subset of the source hierarchical tree, each of said one or more clients is further configured to generate one or more peer actors on the client; wherein said one or more peer actors on the client comprise executable code for performing tasks that are in addition to tasks performed by the one or more actors on the server; and provide a communication link between each of said one or more peer actors of the replicated second hierarchical tree on the client and a corresponding actor of the second hierarchical tree on the server.
 20. The apparatus of claim 19, wherein each said actor comprises a tree of hierarchically linked nodes, said nodes comprising one or more objects.
 21. The apparatus of claim 20, wherein said nodes further comprise one or more nested actors.
 22. The apparatus of claim 19, wherein each of said communication interfaces is secured.
 23. The apparatus of claim 19, wherein said generating a dataset comprises: obtaining inclusion criteria from a parameter set; traversing said source hierarchical tree to determine nodes of said source hierarchical tree that comply with said inclusion criteria; obtaining a pre-initialized object for each of said nodes that comply with said inclusion criteria; generating a client graph comprising said pre-initialized objects.
 24. The apparatus of claim 23, wherein said traversing said source hierarchical tree is on a node-by-node basis.
 25. The apparatus of claim 23, wherein said dataset is indicative of the full client graph.
 26. The apparatus of claim 19, wherein said dataset comprises a subgraph for updating the replicated subset of the source hierarchical tree of said client.
 27. The apparatus of claim 23, wherein said pre-initialized object comprises methods and attributes for construction and initialization of said client graph.
 28. The method of claim 1, wherein the function to be performed by the distributed application comprises rendering a scene.
 29. The computer program product of claim 10, wherein the function to be performed by the distributed application comprises rendering a scene.
 30. The apparatus of claim 19, wherein the function to be performed by the distributed application comprises rendering a scene. 